Forward environment variables through runtime exec - #34
Conversation
commit: |
68f24da to
7171371
Compare
7171371 to
1662c19
Compare
aron-cf
left a comment
aron-cf
left a comment
There was a problem hiding this comment.
I'm going to see if I can refactor out the command vs module distinction. But the feedback for now stands.
| ``` | ||
|
|
||
| `input` is accepted by structured module backends and rejected by command backends. `cwd` is the command working directory or the base for durable relative module imports. A handle is single-consumer: call `result()` or consume its event stream, not both. Repeated `result()` calls return the same promise. `backend` records the resolved backend needed for later reattachment. | ||
| `input` is accepted by structured module backends and rejected by command backends. `env` is accepted by command backends and rejected by module backends; its values override that command's inherited environment without changing later executions. `cwd` is the command working directory or the base for durable relative module imports. A handle is single-consumer: call `result()` or consume its event stream, not both. Repeated `result()` calls return the same promise. `backend` records the resolved backend needed for later reattachment. |
There was a problem hiding this comment.
We should support piping env into module backends too, in a worker any env variable is populated on process.env.
|
Superseded by my PRs that refactors the JavaScript backend to align with how the container shell interface works — the shell/command env path lands in #39 , and the env option surface plus JavaScript-runtime The module-backend rejection in this PR was dropped so env reaches the JavaScript runtime via |
2 participants
No description provided.